structaccess: match encoding/json on ambiguous embedded fields - #6468

The repeated json tag is what the fixture exists to exercise.

Co-authored-by: Isaac

From the review: a struct embedding a pointer to itself sent the embedded-field search round
forever whenever the key was not found at all. Both the value and the type walk now skip a
type they have already visited.

Co-authored-by: Isaac

From the review: the cycle guard deduplicated types globally, so a diamond -- two embeds
reaching one type, putting the name at the same depth twice -- was only visited once and
resolved to a field encoding/json omits. Types are now excluded only from earlier levels, so
the two paths within one level produce the two matches that make it ambiguous.

Co-authored-by: Isaac

From the review: two embedded pointers declaring one json name at the same depth make it a name
encoding/json omits, but the value walk skips a nil embed, so whether the name resolved depended
on which pointers happened to be set. Get and Set could reach a field ValidatePattern rejects.

The value walk now asks the type walk first, so all three agree on which names exist.

Co-authored-by: Isaac

… index

Two disagreements with encoding/json, both found by the new agreement tests, and both
fixed by moving field resolution wholly onto the type and following the index chain it
produces -- which is how encoding/json itself resolves a name.

A name declared behind a nil embedded pointer and again deeper down resolved to the deeper
field. encoding/json picks the shallower declaration and then serializes nothing, because
the pointer is nil, so the deeper field is a field the wire format never carries: Get
returned a value that could not be sent and Set wrote where nothing would read. Resolving
on the type and then walking the value means a nil pointer on the winning path reads as an
absent field. Comparing the owner *type* is not enough, because one struct type can be
reachable by two paths.

An anonymous field carrying a json name is a named field to encoding/json -- it serializes
as a nested object under that name -- but the embedded search flattened it anyway. So
"value" resolved on a type that emits {"leaf":{"value":...}}, while "leaf.value", the path
that is actually on the wire, did not resolve at all. Both directions now agree.

The index-chain resolution also replaces the parallel breadth-first walk over values, so
the two searches can no longer drift: findFieldInStruct, embeddedStructs and
embeddedStructTypes are gone.

Co-authored-by: Isaac

Three more from the review, all in name resolution:

At one depth, encoding/json prefers the field whose json tag names it over one that merely
has the matching Go field name; only a genuine tie is ambiguous. The search counted both as
matches and reported the name as not found, so a field the wire format does carry was
unreachable.

A field whose tag sets only an option -- `json:",omitempty"` -- has no json name, so
encoding/json serializes it under its Go field name. The search matched tag names only, so
such a field could not be resolved at all, while structwalk already emitted it under the Go
name: the two disagreed about a field that is plainly on the wire.

Only an anonymous *struct* is promoted. An embedded scalar, slice or interface is a member
named after its type, but IsFlattenedEmbed called it an embed, so structwalk and structdiff
placed its contents at the parent path.

No resource type has any of these shapes: the refschema golden is unchanged.

Co-authored-by: Isaac

…/json does

encoding/json walks an embedded type once per level however many members reach it, so a name
declared *below* a type reached by two routes is not ambiguous -- it resolves along the first
route. A name the duplicated type declares itself is ambiguous, and json serializes neither.

The search treated every route as independent, so it called the first case ambiguous and
reported a name as not found that the wire format does carry. Verified against json rather
than reasoned about: a diamond over the declaring type marshals to {}, while a diamond one
level above it marshals to {"value":"left"}.

The internal/readonly skip keeps its existing behaviour, with a comment recording that it
diverges from encoding/json: such a field shadows a same-named field further down, so
skipping it lets the deeper one win. resources.App is the live example. Rejecting the name
outright instead would make ${resources.apps.*.url} unresolvable, so that is a decision
about what internal means rather than a fix to make here.

Co-authored-by: Isaac

The fifth review round claimed a remaining tagged/untagged bug for a repeated embedded type.
It does not reproduce: the counterexample used omitempty fields left at their zero value, so
"omitted because empty" was indistinguishable from "not serialized at all". With values
populated, all four combinations agree.

They are worth keeping, since the reasoning is easy to get wrong in either direction, so the
table asserts each against encoding/json rather than against a hand-written expectation: a
repeated type declaring the name itself is annihilated, its tagged name losing to a sibling's
untagged X under "X", a repeated untagged name not colliding with the tagged one at all, and
the shallower of two routes winning.

Co-authored-by: Isaac

encoding/json skips a field only when its json tag is exactly "-". A tag whose name part is
"-" followed by options -- json:"-,omitempty" -- names the field "-" and serializes it like
any other name. structtag's parsed name reports "-" for both, so every caller that branched
on the parsed name conflated them: structaccess could not resolve such a field, and
structwalk and structdiff left it out.

structaccess.IsSkippedField now makes the distinction from the raw tag, and the four packages
share it. The structwalk fixture already had two such fields, added as "fixture for odd tag
handling"; its expectation asserted they were skipped, which is what encoding/json does with
json:"-" and not with what they actually carry. Verified against json.Marshal:
{"-":"o","kept":"k"}.

No resource type has the shape -- the refschema golden is unchanged.

Co-authored-by: Isaac

Without it the test only confirms Set wrote to some field json serializes.
If Get resolved to a different (deeper) field the round-trip would be wrong
and all existing assertions would still pass.